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METHOD AND SYSTEM FOR CUSTOMER SERVICE PROCESS MANAGEMENT 
FIELD OF THE INVENTION 

This invention relates to computer systems, and more particularly to workflow 
systems, and even more particularly to customer service process management systems or 
customer relationship management (CRM) systems. 

DESCRIPTION OF THE RELATED ART 

Service industries require planning and coordination of services across multiple 
service providers in multiple locations across time. This is particularly true in service 
industries offering complex professional services, including financial services, insurance, 
legal services, consulting services and health care services. In such industries, work can 
be conceptualized as falling into two categories. In the first category, service providers 
(or sales personnel serving as agents of service providers) work to develop a plan or 
proposal for services to be provided to a particular customer to meet their individual 
needs. In the second category, service providers work to deliver the services according to 
the plan or proposal. In recent years, computer-based systems have been developed to 
facilitate both of these categories of work. 

In the first category, developing plans or proposals, computer-based systems have 
been developed in the context of services associated with products. "Product 
configurators" have been developed that allow entry of metadata describing product and 
service components and their logical relationships, then allow entry of information 
regarding a particular prospective customer, and then assist in the generation of complete, 
valid, non-ambiguous configurations, including needed services associated with products. 
For example, if a customer orders a particular computer system configuration, 



appropriate installation and training services are included in the configuration. Systems 
have been developed that query the user to determine the customer's needs and then 
generate a customized, printed proposal describing the features and benefits of products, 
including automobiles. In another example, a system uses rules to automatically generate 
a customized insurance policy document. In another example, a system generates project 
plans and specifications for proposed building construction projects. In the health care 
field, "template charting" systems have been developed to facilitate the preparation of 
medical chart notes, including the "plan of care" section, and medical order entry systems 
have been designed that offer pre-prepared "order sets" to facilitate quick, consistent 
entries and rule-driven "reminders" and "alerts" which alert the user about needed health 
care services or inappropriate services that have been proposed or ordered for the 
customer. 

In the second category, service delivery, computer-based systems have been 
developed to manage the flow of work among a team of service providers. These 
systems are known as "groupware" or "workflow" or "workflow automation" systems. 
Workflow systems generally provide a capability for entering metadata describing the 
sequence of tasks or activities in a work process, the resources required to execute each 
task, and the data needed to manage the flow of activities and to execute each task. The 
component of a workflow system used to enter such metadata is variously known as a 
"workflow builder", a "workflow authoring tool" or a "process definition tool." 
Workflow systems also generally include a component that manages the execution of 
individual workflow instances, such as a workflow to process a particular insurance claim 
for a particular auto accident. This component is variously known as a "workflow 



engine," a "workflow automation server ," or a "workflow enactment service.'This 
component tracks the status of each workflow instance, determines what task is needed 
next, determines what human or system resources to marshal to execute the task, and 
communicates with those resources to transport the needed data to and from the 
resources. In these systems, an instance of a workflow is generally initiated by 
completing a computer-based form that provides the data needed to get the workflow 
started. Workflow systems increase the efficiency of service delivery, since they are able 
to route the right task to the right person or machine at the right time. They increase the 
consistency and quality of service delivery, since they track work according to metadata 
which can define best practices. They also increase the reliability of services, since 
bottlenecks and errors can be identified and managed. Some workflow systems provide a 
generic framework that can be adapted to a wide variety of service-delivery processes. 

The emergence of the Internet has greatly increased the value of both categories 
of systems. For planning and proposal development work, the Internet facilitates access 
by field sales personnel or service providers and enables direct entry of customer data by 
customers. For example, web sites have been developed enabling prospective car buyers 
to enter preferences and receive a proposal for a car. For service delivery work, the 
Internet allows work to be distributed across organizational boundaries, geographic 
locations and disciplines. 

Although these two types of systems have provided great benefits for consumers 
and service providers, there is an opportunity for significant improvement. First, the 
linkage or integration of the two categories of work (developing plans/proposals and 
service delivery) is poor. The form-based initiation for workflow instances in existing 



workflow systems works adequately for simple service-delivery processes, but is 
inadequate to use for planning of complex services where customers have multiple 
problems and needs that can only be met with a tailored collection of services. For 
example, in the health care field, existing medical order entry systems can handle the 
entry of a single laboratory, or even a set of orders commonly used for a particular 
purpose. But they are not up to the task of managing the creation of an overall plan of 
care for a patient with multiple health problems, particularly those that are being 
addressed by an inter-disciplinary team of health care service providers. And even for 
simple laboratory orders, existing order entry systems do not manage the entire process of 
communicating the results to the right people, escalating the communications process if 
people are unavailable, initiating follow-up services, etc. 

Another inadequacy in service planning and proposal development systems is the 
difficulty in tailoring plans and proposals to the individual needs and problems of the 
customer, particularly given the large number of potential problems and the huge number 
of possible combinations of problems that a given customer may have. For example, in 
the health care domain, patients may have multiple health problems, selected from a 
universe of possible problems at least in the tens of thousands, and each of which may 
have a variety of different presentations. Managing metadata to handle this variation can 
be prohibitively expensive. 

Another inadequacy is the difficulty in simultaneously meeting the needs of a 
large population of customers with changing and emerging needs. Frequent review of 
each individual customer's service plan is usually infeasible. 



Many existing systems use rule-based alerts to identify erroneous or conflicting 
information, or reminders to identify missing needed services. But if there are a large 
number of such alerts and reminders, as are often required for complex professional 
services, maintaining the quality and accuracy of the associated metadata is difficult. As 
a result, the proportion of inappropriate alerts and reminders increases over time, creating 
a burden of users and eventually creating a "boy who cried wolf problem where users 
ignore valid alerts and reminders because they have given up on them all. 

In complex service industries, customers often have difficulty understanding 
service plans and service providers do not always have time to explain. Although some 
systems produce printed proposals with embedded explanatory material, this is not 
available in system that solves the other problems described herein. 

In health care and some other service industries, it is a legal requirement that 
service providers formally document the services that they provide, as well as their plans 
for delivering services in the future. Documentation of services provided is also a 
requirement for fee-for-service billing. Creating service plans and documenting services 
provided for legal or billing purposes represents a duplication of work. Although there 
are systems designed to assist in the creation of medical chart notes, no existing system 
integrates this function into a flexible workflow automation system to eliminate this 
duplication. 

Existing face-to-face processes for gathering input from multi-disciplinary teams 
of service providers into service plans is prohibitively expensive and logistically difficult 
for busy teams. For example, in the health care field, "tumor boards" and "inter- 
disciplinary clinics" are used to provide a mechanism for users in different disciplines 



and specialties to provide input and collaborate in the development of a plan of care for a 
patient. But the great expense of these meetings relegates this practice to only the most 
serious and academically interesting cases within advanced medical centers. Systems are 
not available to incorporate inter-disciplinary input into the development of a care plan 
that can be used for automatic initiation of workflows to manage execution of the plan. 

SUMMARY OF THE INVENTION 

In view of the above, it is an object of the present invention to provide an 
automated system and method for customer service process management, including the 
inter-disciplinary preparation of service plans or proposals for individual customers, the 
automated management of the execution of such plans, and the population-level 
identification of needs and specific services to meet those needs. 

It is another object of the invention to facilitate the creation, maintenance and 
continual improvement of the metadata needed for such a system. 

A further object of the invention is to provide a system and method for customer 
service process management that allows for the automated generation of customer- 
understandable service plans, workflow status, and result information, provided directly 
to customers on-line or by conventional media. 

A still further object of the invention is to provide a system for distributing 
service plan metadata and associated workflow metadata to service providers, such that 
the distributed metadata can be either used in the distributed form, or updated for 
personalization needed by a particular service provider. 



These and other objects and advantages are obtained by providing for methods 
and systems for customer service process management. In one embodiment the present 
invention, the system includes at least one client computer used by customers and at least 
one client computer used by service providers, which are each interconnected via a 
communications network to certain ones of a database service computer, a workflow 
automation server computer, a web application server computer, and external server 
computers. Using such a system, customer service processes are managed both for 
individual customers and populations of customers. 

In a specific embodiment within the health care field, a generic metadata supplier 
provides generic care plan templates, generic workflow process specifications, and 
generic workflow task type metadata to a service provider. 

Then, a user such as a clinician associated with the service provider adapts the 
generic metadata or creates new metadata according to preferred specifications to obtain 
local metadata, including local care plan templates, local care process specifications and 
local workflow task type metadata. Then, a clinician or other user associated with the 
service provider creates or updates a draft care plan for a patient using the generic or 
local care plan template metadata and patient specific information. The draft care plan 
includes a list of specific services (i.e. health care interventions) to be provided to the 
patient. The draft care plan can be routed to members of an inter-disciplinary team for 
input. 

Once the care plan is finalized, workflow processes are instantiated for each 
intervention in the care plan. An itinerary is created for any required patient encounter, 
optimized to account for pre-existing process instances. A workflow automation server 



manages the execution of eachintervention, invoking resources according to the 
workflow process specification metadata and workflow task type metadata. 

In another aspect, the present invention allows for the analysis of outcomes datato 
identify opportunities for improvement of the associated metadata. Graphical tools for 
managing metadata and automatic generation of feedback data regarding the 
appropriateness of metadata for reminders and alerts provides these capabilities. 

The methods and systems according to the present invention also allow for the 
selection of a population of service customers, the analysis of population data to identify 
opportunities for needed services, and the initiation of specific services for the entire 
population through batch updates to individual service plans. The resulting updated 
service plans are then executed using the same method and system components described 
above. 

BRIEF DESCRIPTION OF DRAWINGS 

The above and other objects, features, and advantages of the present invention are 
further described in the detailed description which follows, with reference to the 
drawings by way of non-limiting exemplary embodiments of the present invention, 
wherein like reference numerals represent similar parts of the present invention 
throughout several views and wherein: 

FIG. 1 is a block diagram of a computer-based system for customer service 
process management. 

FIG. 2 is an overall process flow diagram of a process for using the system for 
personal care management, population care management, and metadata improvement. 

8 



5 FIG. 3 is a diagram representing an example care plan 

FIG. 4 is a diagram of the relationships between important metadata entities used 
by the system. 

FIG. 5 is a diagram representing an example structured sentence data item. 

FIG. 6 is a diagram representing an example question data item. 
10 FIG. 7 is a diagram representing an example care plan template. 

FIG. 8 is a diagram representing an example care process specification. 

FIG. 9 is process flow diagram providing more detail of the method of creating 
and updating care plans for individual patients using the system. 

FIG. 10 is a process flow diagram providing more detail of the method of 
1 5 instantiating workflow processes and creating encounter itineraries using the system. 

FIG. 1 1 is a process flow diagram providing more detail of the method of 
executing workflow process instances using the system. 

FIG. 12 is a process flow diagram providing more detail of the method of 
population care management using the system. 

20 

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED 

EMBODIMENTS 

25 The figures depict a preferred embodiment of the present invention for purposes 

of illustration only. One skilled in the art will readily recognize from the following 



9 



discussion that alternative embodiments of the structures and methods illustrated herein 

may be employed without departing from the principles of the invention described herein. 

Referring to FIG. 1, there is shown a system 100 for managing customer service 

processes in accordance with the present invention. The major components of system 

100 include at least one client computer 1 10, such as a Pentium based personal computer, 

containing a central processing unit (CPU) 1 15, memory 120, at least one display device 

125, at least one input device 130 (such as a keyboard and a mouse pointing device), and 

a network interface 135. These components of the client computer 1 10 are 

interconnected via a bus 140. Customer service providers and customers directly interact 

with client computers such as the one illustrated as 1 10. The network interface 135 

provides a means for communication between the client computer 110 and other 

computers on a communications network 145. The system 100 also includes a database 

server computer 150 for storing service customer data and metadata, a workflow 

automation server computer 160, and a web application server computer 165. Application 

programs, each containing program instructions correlated to the necessary functions 

being performed, are stored in corresponding memories for these computers and servers, 

to perform in the manner detailed below. Each of these computers is of conventional 

design, with internal components as generally described for the client computer 110. The 

database server computer 150 includes a persistent storage device 155, such as a hard 

disk drive. These computers may also be interconnected via communications network 

145 to one or more external server computers 170, such as computers used for legacy 

systems within the various organizations involved in the customer service process. It 

should be noted that, although FIG. 1 illustrates the use of a single, separate computer 

10 



5 serving as each of the client computer 110, database server computer 150, workflow 
automation server computer 160, web application server computer 165 and external 
server computer 170, many other embodiments are possible. In accordance with 
conventional network computing methods, several of these computer functions could be 
run on a single physical computer device. Alternatively, several of these computer 

10 functions could be distributed to be run on a plurality of physical computer devices. 
Also shown is a service customer computer 180, which can remotely contact the single 
separate computer, preferably via the Internet, to provide and receive information as 
discussed hereinafter. 

Referring now to FIG. 2., the overall method for customer service process 

15 management is illustrated in an embodiment in the domain of health care delivery. It is 
understood that while the embodiment in the domain of health care delivery has certain 
novel and unique aspects, that the present invention also has unique aspects that are not 
limited to the domain of health care delivery. Accordingly, subsequent figures provide 
additional detail for the various parts of this overall method, and are described with 

20 reference to the domain of health care delivery. The first step 200 in this method is to 
create and edit the various types of metadata used by the system. These metadata, 
including libraries of generic metadata, which include structured sentence data items, and 
generic care plan templates and generic workflow process specification metadata, which 
include process specifications and report specifications are described in detail below, all 

25 of which are preferably obtained from a generic metadata supplier, which supplier 
preferably provides generic care plan template metadata as well as generic workflow 
specification metatadata and workflow task type metadata associated therewith. This 



5 generic metadata is preferably disseminated by the generic metadata supplier in generic 
metadata modules transmitted via the Internet to the service provider While described 
above as "generic metadata/' it should be understood that the metadata will typically be 
highly specific to the type of plan that is being implemented. In many instances the 
service provider will use the generic plan metadata "as is," without modification. Since, 

10 however, this metadata is capable of being adapted to the needs of a particular service 
provider, the descriptor "generic" is used. Nevertheless, one of the important aspects of 
the present invention is the ability of the generic metadata supplier to provide information 
that is extremely current, and therefore can widely disseminate the most current medical 
treatments for a specific medical problem. 

15 A user such as a clinician associated with the service provider organization can 

edit the received generic metadata or create new plan metadata according to preferred 
specifications to obtain local metadata. Of course, it is understood that the local metadata 
can be created in other manners as well. 

Using generic or local plan metadata, including care plan template metadata, the 

20 user, typically the clinician, creates 215 a draft care plan for an individual patient or 
updates a pre-existing care plan for such a patient. This care plan is then stored in the 
database server computer 150. 

Turning to FIG. 3, an example of a care plan is provided. The care plan 370 
includes a list of the health problems being addressed for the patient 372. For each health 

25 problem, the care plan includes a list of the management goals 376, relevant facts 374,the 
services (health care interventions) 378 that are planned, in progress or already provided 
for that health problem, and the findings that are associated therewith. In the health care 



5 domain, services include diagnostic tests, treatments, referrals to other health care 

providers, or return visits. Services can also include protocols 382 that describe a logical 
sequence of other services over time, such as a diagnostic work-up protocol or a cancer 
treatment protocol Each of these health problems 372, goals 376, facts 374, services 
378, protocols 382, and the findings associated therewith, are preferably created in the 

10 health care plan 370 as structured sentence data items, described in more detail below 
with respect to FIG. 5. 

Returning back to FIG 2., the user, typically the clinician, may electronically 
route 230 a draft care plan to other members of an inter-disciplinary clinical team to 
gather their feedback and input to the draft care plan. 

15 Once the draft care plan is finalized, the system instantiates workflow processes 

in step 220 for each service in the care plan. The instantiation of the workflow processes 
begins in a manner similar to that for the instantiation of the care plan. The generic 
workflow specification metadata, which workflow specification metadata is associated 
with corresponding structured sentences for services, can be edited by a clinician or other 

20 user associated with the service provider or new workflow metadata can be created 
according to preferred specifications to obtain local workflow specification metadata. 
This workflow specification metadata includes specified tasks which are of task types 
described in workflow task type metadata. Workflow task type metadata includes 
information about the data and resources required for a particular workflow task type. As 

25 with workflow specification metadata, generic workflow task type metadata can be used 
"as is," or it can be adapted or created anew by users associated with service provider 
organizations to meet local needs. Of course, it is understood that the local workflow 



5 process specification metadata and local workflow task type metadata can be created in 
other manners as well. 

Using generic and local workflow process specification metadata, the clinician or 
other user can create workflow process instances associated with the structured sentence. 
As with the "generic care plan template metadata" discussed above, it is also true that the 

10 "generic workflow process specification metadata" is also highly specific with regard to 
current medical practice as well, and may well be used "as is." Significant to the present 
invention is the association of a workflow process specification with a particular 
structured sentence for services, and the ability of the present invention to group 
structured sentences and associated structured sentences for services together to provide a 

1 5 resulting product that can efficiently track complex interrelationships in the plan. 

Thus, the workflow process instances provide the basis for tracking the planning, 
execution and follow-up of the associated services. When the care plan requires a patient 
encounter such as a return clinic visit, the system automatically generates 235 an 
encounter itinerary, describing in a patient understandable report where the patient is to 

20 go, what she needs to do to prepare, and what she can expect during the encounter. 
Whenever new workflow process instances are created corresponding to new services 
needed based upon new instantiated structured sentences for services being added to the 
care plan, existing encounter itineraries are automatically re-evaluated and, if necessary, 
adjusted to optimize the encounters to make them efficient and coordinated for both 

25 patients and health care providers. For example, if a patient is already scheduled to come 
to the medical center in three days, and a test has just been ordered that must be 
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5 completed within the next week, the test is scheduled to coincide with the scheduled visit 
if possible. 

Each active workflow process instance is executed 225, invoking resources such 
as clinical staff and automated services as needed according to workflow process 
specification metadata. The workflow automation server computer (160 from FIG. 1) 

10 manages the tracking and execution of these workflow instances. 

In addition to supporting the management of the care of individual patients 205 , 
the system also supports the process of population care management, as shown by 
process 210. More specifically, the user selects, as shown by step 240, a population of 
patients of interest. The user then analyzes in step 245 data for the selected population in 

15 order to gain an understanding of the population and to identify specific needs in the 

population, including needed services. The user then initiates population interventions in 
step 250, essentially starting a batch process that updates the individual care plans of the 
members of the selected population of patients. For example, the clinician can determine 
that a population of smokers could benefit from a smoking cessation educational 

20 intervention and then add that service to the care plan of each smoker who has not 
already received the service. The execution of the updated care plan is handled by the 
same process steps 220, 235, 225 used for care plans that are updated on an individual 
basis. 

Another aspect of the present invention illustrated in FIG. 2 is a method for 
25 continually improving the metadata based on the performance of a customer service 
process. The metadata that is improved could be the local metadata for a particular 
service provider organization, or the generic metadata from the generic metadata 



5 supplier. In either instance, based on data generated through the personal care 

management 205 and population care management 210 processes, the user analyzes in 
step 255 feedback data on the appropriateness of alerts and suggested plan of care items, 
as well as data on clinical practice and outcomes to identify opportunities for 
improvement in the metadata. For example, the user could discover that a particular alert 

10 is dismissed as "inappropriate" a large percentage of the time, or a particular service 
protocol could be found to produce poor health outcomes. Bases on the insights gained 
through this analysis, the user edits 200 the metadata. 

Referring to FIG. 4, the relationships between the various types of metadata are 
illustrated. Additional figures 5-8 are provided to show examples of some of the 

15 metadata types, described below. At the center of this metadata model are data items 
300. There are three important types of data items: structured sentences, questions and 
queries. Structured sentence data items are used to describe health problems being 
addressed, goals of management, relevant findings, and health care services. Structured 
sentence data items are comprised of a subject term, and may include one or more 

20 attribute terms that modify the subject term. Both subject and attribute terms are of types 
such as numeric, binary, date, or enumerated. For enumerated (mutually exclusive 
multiple choice) terms, the term contains a collection of response options (valid values). 
There preferably is a structured sentence for each different health problem 372, goal 376, 
fact 374, service 378, protocols 382, and the findings associated therewith as discussed 

25 above with respect to the care plan 370 illustrated in FIG. 2. For greater understanding, 
reference will now be made to FIG. 5, and a specific example of a structured sentence 
data item for a particular drug is illustrated. The subject 850 identifies the drug as 



5 Furosemide. Attributes could include, for example, the dose 852, the route 854, the form 
858, the frequency 862, and the date prescribed 866. Other possible attributes, such as 
the number of refills allowed, the amount of the drug to be dispensed, whether or not the 
associated prescriptions should be sent to a pharmacy, etc., are not illustrated in FIG. 3 A. 
For the route 854, a collection of valid response options 856 are provided, including oral, 

10 intravenous, inhaled aerosol, etc. For the form 858, valid response options 860 include 
capsules, tablets or solution. For the frequency 862, valid response options 864 include 
once, QD (daily), Q AM (once a day in the morning), BID (twice a day), PRN (as 
needed), etc. 

Referring to FIG. 6, another type of data item is a question. Questions are used 
1 5 for questionnaires which are administered to patients as part of a protocol to collect 

baseline history, risk factor and functional status information, or to monitor compliance 
with treatment advice or outcomes of care. Questions may also be incorporated into data 
input forms that are completed by users, typically clinical staff, as part of the execution of 
a care plan. Questions 870 may have explanatory text 872 and one or more data elements 
20 874 and basic layout information, possibly including textual elements and graphical 

elements 875. Data elements have types.. For data elements of type enumerated, the data 
element includes a collection of response options 876, which may optionally have default 
values defined. Unlike the attributes in structured sentence templates, the data elements 
in questions do not necessarily modify the same subject term. In the example, each data 
25 element relates in general to difficulty in performing activities, but each describes a 
different activity .Questions may be designated by the author as being intended to be 
answered by clinicians (as part of input forms) or patients (as part of questionnaires). 



5 The answers provided to questions can then be used to create facts 374 as referenced in 
the care plan 370 of FIG. 2, to provide needed information for attributes associated with 
structured sentence data items discussed above, or to provide attributes needed in order to 
determine workflow routing, determine the state of an alert rule, or the like, as described 
below. In a preferred embodiment, the patient can remotely enter answers to questions 

10 from a customer computer 1 80 that accesses the computer system associated with the 
service provider via the Internet. 

Referring back to FIG. 4, the third type of data item 300 is queries. Queries 
provide a way to introduce a layer of abstraction into the authoring of "higher order" 
metadata including care plan templates, workflow process specifications, etc. Queries 

15 return data values based on manipulation of instances of other data items. An example of 
a query would be a query data item which combined information from a number of 
related data items, such as a set of data items related to "magnitude of back pain." In this 
example, the query could map the "very painful" response option in one question item to 
the "excruciating" response option in a structured sentence item. Once defined, such a 

20 query can be used and re-used as if there was a single data item for magnitude of back 
pain. 

Data items are associated with translations 310 to one or more languages or sub- 
languages, including such sub-languages as "English Medical Terminology," "English 
Lay Terminology - Educated," and "English Lay Terminology - Simplified." These 
25 translations map clinician terminology and abbreviations to patient-understandable 

versions. For example, the clinical abbreviation "CHF" could be mapped to the complete 
phrase "congestive heart failure." In addition, the patient-understandable translation for 



5 CHF could also include additional explanatory text, such as a description of what are the 
causes and the common symptoms of congestive heart failure for the example provided 
above, or a description of the reason that a particular medication is being taken, for 
example. Thus, in a specific example, the clinical terminology of a medication order of 
"Lanoxin 0.25 mg QD" could be translated to the following: 

10 "Medication - Lanoxin, which is genetically called Digoxin. You are to take one 

tablet each day. Each tablet contains 025 milligrams of the medicine. This 
medicine helps your heart to pump more strongly." 
To accomplish this translation, the associated metadata includes translations at each 
desired part of the clinical structured sentence, including the subject and the attributes. In 

15 addition, the metadata includes additional explanatory text associated with the subject, 
and patterns for constructing a patient-understandable paragraph from the original clinical 
structured sentence. In a preferred embodiment, the patient can remotely receive this 
translation at a customer computer 180 that accesses the computer system associated with 
the service provider via the Internet. 

20 Care plans are comprised of instances of structured sentences created based on 

structured sentence data items, as described previously. In order to facilitate rapid, 
consistent creation of care plans, care plan templates 325 are employed. Care 
plantemplates are metadata structures which may contain an ordered collection of 
structured sentence data items, with particular default values assigned, to be incorporated 

25 into a care plan as a single interaction, as well as informative headers, groupings, 
additional information and links to other information sources. Turning to FIG. 7, an 
example care plan template is provided. In this example the care plan template 390 



5 contains all of the medications usually ordered for patients diagnosed with congestive 
heart failure, as suggested in header 391 . In this template, the individual structured 
sentence data items 392 refer to specific drugs. In addition, the example template 
contains informative headers 393, grouping the drugs into drug classes, with additional 
text 394 providing clinical practice guideline suggestions and a link 395 to additional 

10 reference material regarding a drug class. In a preferred embodiment of the system, when 
a template is selected for inclusion in a patient's care plan, such informative text is 
presented. Then, when the care plan is subsequently signed, this informative text, as well 
as any structured sentences with unchecked checkboxes, will be removed from the care 
plan. 

15 Returning to FIG. 4, in order to facilitate access to the available care plan 

templates 325 that relate to a health problem being addressed for a patient, problem group 
330 metadata is employed. Each of the structured sentence data items 300 that describe 
health problems are mapped to problem groups 330 and are stored 155. For example, a 
group of structured sentence data items for various types of congestive heart failure can 

20 be mapped to a problem group of congestive heart failure. The relevant care plan 
templates 325 are also linked to the problem group, as are other types of metadata, as 
described below. For example, if the problem "cardiomyopathy" (a type of CHF) were 
mapped to the problem group "CHF", and then the problem "cardiomyopathy" is 
included in the care plan for an individual patient, all of the care plan templates related to 

25 CHF could be easily accessed. Also referred to in FIG. 4 are "note templates," which 
provide the user with the capability of including observations at a point in time onto the 
patient data, such as aspects of the patient's history and physical examination. 



5 For each structured sentence data item 300 that relates to a service, a workflow process 
specification 335 preferably exists that describes the sequence of activities involved in 
executing the service. Turning to FIG. 8, an example workflow process specification is 
provided. Workflow process specifications include starting nodes 800, termination nodes 
805, tasks 810, 815, 820, 825 (corresponding to the associated activities), and routes 830 

10 (defining the sequence of tasks). Some task nodes 820 refer to specific activities to be 
performed by a human or system resources specified in the task properties within the 
workflow specification. Other task nodes 815 refer to sub-processes which are invoked at 
that point in the parent process. Still other task nodes 8 1 0, 825 are decision nodes that 
determine the logic of the sequence of tasks. It should be noted that different 

15 embodiments of the system may use different approaches for determining the logic of 
tasks. For example, one approach used by workflow automation systems in the art is to 
use "task firing rules" or "task conditions," which are rules or conditional expressions 
associated with tasks to determine which tasks or activities are to be invoked at a 
particular point in time for a particular workflow process instance. In another example, 

20 another approach used by workflow automation systems in the art is to use "routing 
rules," which are rules or conditional expressions associated with the routes connecting 
tasks to one another. Such rules or conditional expressions determine which routes are to 
be traversed, thereby determining which tasks or activities to invoke for a particular 
workflow process instance. The workflow process specification also specifies the data 

25 items needed to support both the execution of the tasks and the routing rules. 

Referring back to FIG. 4, each task incorporated into a workflow process 
specification is drawn from a collection of available workflow task types 340. Task type 



5 metadata describes what data items are needed for a particular task and the mechanism 
for invoking the resources required for execution of the task. Task type metadata also 
includes instructions about the use of the task type. For some tasks within a workflow 
process specification, additional metadata is needed to describe how to execute the task. 
For example, if the task is to display a data entry form on the screen to be completed by a 

10 clinician or to present a questionnaire to be completed by a patient, input form and 

questionnaire specification 345 metadata is used, detailing the data items, field validation 
rules and layout of the form or questionnaire, among other things. In another example, if 
the task is to post a laboratory result to the database or print a report of patient-specific 
information, output result / report specification 350 metadata is used, detailing the data 

15 items and layout of the result record or report, among other things. 

To support the clinician in gaining an overview of the patient's status regarding a 
particular health problem being addressed, patient summary view 360 metadata describes 
the layout and underlying data queries needed to summarize patient data related to a 
problem group 330. To support the clinician gaining and overview of the status of a 

20 population of patients with a particular health problem, and to identify needed services 
for such populations, population analysis report 365 metadata is used to describe the 
layout and underlying data queries needed to generate appropriate charts, graphs and 
tables. 

Referring to FIG. 9, more detail is provided on the method for creating or editing 
25 a care plan for an individual patient (steps 215 and 230 in FIG. 2). This process begins 
with the clinician user viewing patient records 400 to gain familiarity with the case. 

Records include the pre-existing care plan, previously created clinical notes 

22 



(documenting previous patient encounters and procedures), results of tests, consultations, 
or questionnaires obtained through the execution of pre-existing care process instances, 
and basic profile information (demographics, insurance information, etc.) entered by the 
patient or health care providers. Patient summary views summarize the available 
information related to a particular health problem being addressed for the patient. These 
records include data stored in the database server computer (150 in FIG. 1), or in external 
server computers (170 in FIG. 1). Examples of external server computers providing 
patient information would include a computer serving data from an external electronic 
medical record, clinical data repository, billing, or managed care application. 

The clinician user then selects 405 templates to incorporate into the care plan.. 
The clinician then accepts or rejects 410 the individual structured sentences that have 
been incorporated into the care plan. The clinician then modifies attributes 415 of 
accepted sentences to tailor the care plan for the individual patientBased on user 
interaction and system events, the system may propose additional sentences 420 for 
incorporation into the care plan. 

Referring back to FIG. 3, an example care plan display in a preferred embodiment 
of the system illustrates the user interactions involved in care plan creation and editing. 
Triangle symbols 383 to the right of the care plan header provide a means to call up and 
* select from a list of commonly used or preferred templates. As described above, if 
structured sentences for health problems have already been entered, care plan templates 
related to the associated problem group are readily accessible by clicking on triangle 
symbols 384 to the right of the corresponding problem sentence. 
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5 In this example embodiment, structured sentences that have been incorporated 

into the care plan during the current session are displayed with check-boxes 388, 390, 
which have default true/false values in the template, and which can be checked or 
unchecked by the user in the care plan to accept or reject the sentences into the care plan. 
Unchecked sentences are removed by the system at the conclusion of the user session. 

10 The clinician then modifies attributes of accepted sentences by directly clicking on the 
attribute. In the example, an accepted sentence for a prescription for Enalapril 380 may 
be modified to change the dosage by clicking on the current dosage "5 mg". The 
clinician may also add additional attributes by clicking on the triangle symbol 386 to the 
right of the sentence to reveal a list of available attributes for this structured sentence data 

15 item, such as number of pills to dispense, number of allowed refills, etc. Once a given 
structured sentence data item is selected or checked, that instance of the structured 
sentence, and the tailored information that has been selected, if any, are saved as part of 
the care plan for that particular patient. 

Referring back to FIG. 9, based on user interaction and system events, the system 

20 may propose additional sentences for incorporation into the care plan. For example, if 
the clinician adds a particular drug to the care plan, the system may propose a monitoring 
test needed to detect possible adverse effects of the drug on kidney function. In a 
preferred embodiment, these suggestions are presented as sentences in the care plan with 
an unchecked check-box with a red exclamation point to the left (shown as 392 in FIG. 

25 3). The clinician then accepts or rejects 425 such proposed sentences. 

Based on user interaction and system events, the system may display alerts 430. 
For example, if the clinician adds a particular drug to the care plan that has an interaction 
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5 with another drug already in the care plan, the system may generate an alert to that fact. 
The clinician then views the alert and dismisses the alert 43 5 , and subsequently makes 
modifications to the care plan 440 as needed. When the clinician dismisses the alert, it is 
dismissed as an "appropriate alert" or an "inappropriate alert," and this event is recorded 
in a database. In this manner, the system gathers feedback on alert appropriateness for 
10 use in the process 255 of identifying opportunities to improve the metadata related to 
alerts. 

The system automatically generates in step 445 a patient-understandable version 
of the care plan, with terminology appropriate to the patient's language and preferred 
%Q sub-language (such as more advanced vs. simpler terminology or culturally-appropriate 

fU 1 5 terminology). This translation is accomplished utilizing translation metadata 310, 

discussed above. The clinician may view this version and modify the patient- 
^ understandable version, as shown by step 450, as needed. 

q The system also automatically generates in step 455 a draft encounter note, 

yff including changes to an existing care plan that result from an encounter. The clinician 

y0 20 can modify this note as needed, using note templates metadata or entering free text 
sentences. In a preferred embodiment, the system accepts voice dictation and either 
routes the voice data to a transcriptionist or employs voice recognition technology to 
create a textual version of the material. 

It should be noted that, although FIG. 9 portrays the process of selecting, 
25 accepting and modifying care plan templates, and modifying the patient version of the 
care plan and the encounter note in a particular sequence, the preferred embodiment 
permits these to be done in an order chosen by the clinician user. The clinician continues 



5 this process until the care plan and encounter note are complete in step 465. If the 
clinician determines that input from and inter-disciplinary team is needed, as shown by 
step 470, then the clinician invokes a workflow automation process 475 to route the draft 
care plan to appropriate team members for review and input. The routing of the draft 
care plan is based on workflow process specification metadata (335 in FIG. 4) and is 

10 managed by the workflow automation server (160 in FIG. 1). Once this care plan review 
process is completed, and any needed modifications have been made, the care plan is 
signed 480 to activate it and commit it to the permanent record for the patient. 

In an alternative sequence for this process, the clinician user first invokes a 
workflow process for interdisciplinary care planning. A task in this workflow process 

15 calls for the creation of the draft care plan by one clinician, with subsequent routing to 
other members of the team for review and input. In this alternative sequence, the entire 
process of inter-disciplinary care planning is itself a service which can be incorporated 
into a previous care plan. For example, the care plan for managing a patient with 
congestive heart failure may call for some tests, some medications, a return visit in 3 

20 months, and an inter-disciplinary review and revision of the care plan in 6 months. 

Referring to FIG. 10, more detail is provided on the process for instantiating 
workflow processes and creating optimized encounter itineraries (220 and 235 in FIG. 2), 
Beginning with an activated care plan 550 (one that has been electronically signed by an 
authorized clinician or user), the system instantiates in step 505 at least one workflow 

25 process for each service in the care plan. This is accomplished by invoking the workflow 
automation server (160 in FIG. 1) with reference to a workflow process specification 
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5 (335 in FIG. 4) corresponding to a data item (300 in FIG. 4) in the care plan which 
represents a service. 

For services in the care plan which require a patient encounter such as a clinic 
visit, a home health care visit, a hospital admission or a telephone encounter, the system 
generates in step 510 an encounter itinerary. The encounter itinerary describes the 

10 schedule for the encounter and which resources are needed, including clinical staff, 

facilities, and equipment. The encounter itinerary also contains information about other 
events that must be completed prior to each event during the encounter. An example of 
such a dependency would be a scheduled test that must be completed prior to a scheduled 
treatment. The encounter itinerary includes not only the scheduled times for events in the 

15 encounter, but also required time ranges. For example, a treatment may be scheduled for 
a particular date, but it may be required to be completed any time from one week before 
to two weeks after the scheduled date. For non-scheduled events, the itinerary data 
includes an estimate of the likely date range for the event, based on metadata included in 
the associated workflow process specifications. For example, if a scheduled procedure 

20 must be provided after an unscheduled event to complete a mailed pre-procedure 

questionnaire, the itinerary data for the scheduled event includes an estimate of the likely 
date range that the questionnaire will be completed, based on elapsed time parameters 
that are included in the workflow specification for the process of administering the 
questionnaire. 

25 For newly generated encounter itineraries from step 510, the system follows a 

method for optimizing the efficiency and convenience of the itinerary, given previously 
generated itineraries. If there are any pre-existing active workflow instances for the 



5 patient identified as a result of decision step 515, the system analyzes in step 520 firm 
(scheduled) task event dates and like task event dates for unscheduled event to identify 
"conflicts" and "inefficiences." In this context, a "conflict" is defined as a situation 
where events a scheduled with an infeasible overlap with another scheduled event. In 
this context, an "inefficiency" is defined as a situation where events scheduled for 

10 multiple encounters could be combined into a single encounter, or events within an 
encounter could be rescheduled to reduce the overall duration of the encounter. 

If any such conflicts or inefficiencies are identified in step 525, the system 
automatically generates proposed revisions to encounter itineraries in step 130. The 
system then evaluates the risk in step 535 of automatically accepting the proposed 

15 revisions to the encounter itineraries, using predetermined criteria that is relevant to the 
risk being analyzed. For example, in one embodiment of this aspect of the invention, the 
system could judge as high risk any changes that require the patient to come to the clinic 
on a different day, or earlier on the same day, while judging as low risk changes that 
shorten the duration of an encounter or eliminate the need for an encounter that had been 

20 scheduled near to another encounter. If the risk of automatic itinerary revision is 

calculated to be low in decision step 540, the system revises the encounter itineraries in 
step 545 and these changes are communicated in step 550 to the managers of the clinical 
resources involved. If, on the other hand, the risk of automatic itinerary revision is 
calculated to be high in decision step 540, the system routes a task in step 555 to a human 

25 scheduler to review the itineraries, the identified conflicts or inefficiencies, and the 
proposed changes for consideration. This person makes manual changes, as shown by 
560, to the encounter itineraries as needed. 



5 In either case, the system then generates in step 565 a patient-understandable 

version of any encounter itineraries that were created or revised and communicates these 
to the patient. The patient-understandable version is translated to use terminology 
appropriate to the patient's preferred language or sub-language (such as English - Lay 
Person Educated vs. English - Lay Person Simple). It is also augmented with 

10 information regarding what they need to do to prepare for the encounter, how to get to the 
encounter, and what to expect, as well as links to related educational materials. For 
example, if the patient is scheduled to undergo an outpatient surgical procedure, the 
patient version of the encounter itinerary could include information about the procedure 
and about the anesthesia likely to be used. 

15 The entire collection of active workflow process instances for the patient are then 

executed in step 570, as described below. 

Referring to FIG. 11, more detail is provided regarding the method for executing 
workflow process instances (220 in FIG. 2). This process is managed by the workflow 
automation server computer (160 in FIG. 1) using workflow specification metadata (335 

20 in FIG. 4). The workflow automation server maintains workflow relevant data for each 
process instance, as shown by initial state 600. In this context, workflow relevant data 
includes data needed to control the sequence of tasks and to instantiate work items for 
each task. Workflow relevant data includes the attributes and values of the structured 
sentence for a service which was associated with the workflow process instance. 

25 Workflow relevant data can also include data accessed, created or modified as part of the 
execution of the workflow process instance, such as through queries to service customer 
data, queries to external server computers, the completion of questionnaires and data 



5 input forms by users, execution of computer logic, and other activities or events. Based 
on this workflow relevant data, the system maintains status as shown by step 605 for each 
workflow process instance, creating work items according to workflow specification 
metadata. In the art, this is described as a "coordination service" within the workflow 
automation server. For each work item, the system identifies specific resources needed to 
10 execute each work item, including human resources and system resources, as shown by 
step 610. The workflow specification metadata 335 may directly dictate the specific 
resource required. Alternatively, in a preferred embodiment, the workflow specification 
metadata specifies a "role" or criteria for determining which of the available resources is 
best suited for the task. A separate service, described as an "organization service" in the 
1 5 art, handles the process of identifying the specific resource to be utilized. 

Once the resources required for a work item are identified, the system marshals 
the required resources, communicating information to and from the resource as needed in 
step 615. This process is described in the art as a "transport service," and can be carried 
out by the workflow automation server 160, or, in a preferred embodiment, by a separate 
20 server computer dedicated to that purpose. 

The system then updates the status information in step 620, both within the 
workflow automation server and in the clinician and patient versions of the care plans. 
Within the care plan, this is achieved by adding or modifying attributes of the structured 
sentences in the care plan, or adding one or more new structured sentences relating to the 
25 status of the services in the care plan. This process of updating the status information 
displayed in the clinician and patient versions of the care plan can be done proactively 
(on a "push" basis), as status changes within the workflow automation server. 



5 Alternatively, in a preferred embodiment, the up-to-the-minute status information can be 
communicated outside the workflow automation server at the time that a user chooses to 
view the care plan (on a "pull" basis). The workflow automation server continues to 
manage the execution of each workflow process instance, using a decision step 625 , until 
it has reach a status of completed (or until it is terminated by an authorized user), at 
10 which point the process ends 630. 

Referring to FIG. 12, more detail is provided regarding the method for population 
care management (210 in FIG. 2). According to the preferred embodiment of this 
method, the clinician user first selects a scope for population analysis in step 700. 
yfi Examples of alternate scopes include "my panel," "my clinic" or "my institution." Then, 

fy 15 the clinician determines in step 705 if the population of interest is described by, or 

contained within the population of patients for which their care plan includes a health 
^ problem that has been mapped to a particular problem group. In most cases, this is likely 

C to be true, since the problems groups are defined so as to group patients with similar care 

1 5 plan requirements together. If so, the clinician selects in step 710 a problem group of 

yg 20 interest to further constrain the selected population within the selected scope. 

In any case, the clinician may then decide to further constrain the selected 
population using a population query shown by step 715. A population query is metadata 
defining patient selection criteria. For example, a population query could define the 
subset of patients who are in a high risk category, or the subset who do not have a 
25 particular service included in their care plan. In a preferred embodiment, the clinician 
may layer population queries on top of one another or define new patient selection 
criteria on an ad hoc basis. 



5 Having refined the selection of a population of interest, the clinician may then 

select and view population analysis reports regarding needed services and priorities, as 
shown by step 720. These population analysis reports are displayed based on population 
analysis report metadata (365 in FIG. 4). In a preferred embodiment, the clinician may 
select from available pre-defined reports, or define a new report on an ad hoc basis. 

10 If needed, the clinician may view patient-level information for patients within the 

selected population. In a preferred embodiment, a table listing the individual patients in 
the selected population is displayed, with columns filled with data items relevant to the 
selected problem group. The patient name is the table is implemented as a hypertext link 
to the patient's chart, specifically to a patient summary view for the problem group 

1 5 selected. In this embodiment, the problem-oriented patient summary view would be 
generated based on patient summary view metadata (360 in FIG. 4). 

If needed, the clinician may also manually select a subset of patients within the 
previously selected population. In a preferred embodiment, this is accomplished with a 
check-box user interface included as one of the columns in the table view described 

20 above. 

The clinician continues to refine the population selection and analyze selected 
populations until the clinician understands the services that may be needed for a selected 
population, as shown by step 735. It should be noted that, although this population 
selection and analysis process is presented in FIG. 12 in a particular sequence, a preferred 
25 embodiment would allow the clinician to choose the order of the these steps in an 
iterative fashion. 
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5 Then, if the clinician chooses to initiate a population intervention in step 740, the 

clinician selects one or more care plan templates in step 745 corresponding to the needed 
population intervention. As with the process of creating and updating care plans for 
individual patients, the clinician then accepts or rejects individual sentences in the 
selected template(s) in step 750. The clinician then modifies the attributes of accepted 
10 sentences in step 755 to tailor the care plan fragment to the selected population. An 
authorized clinician then enters and electronic signature in step 760 to activate the 
population intervention. The system then updates the care plan for each patient in the 
selected population to incorporate the sentences in the signed care plan fragment 
Jj (describing the population intervention) in step 765. Subsequently, the system 

Bsc: 

* 1 5 instantiates in step 775 at least one workflow process for each new service in the updated 
; II care plans, and executes these workflow process instances using the same method and 

ljy system components as with care plan updates made for individual patients, as described 

□ on a general level in FIG 2 (steps 220, 235, 225), and in detail in FIG 5 and FIG 6. 

S Although the above description contains many specificities, these should not be 

B 20 construed as limitations on the scope of the invention, but merely as illustrations of the 
presently preferred embodiment. Many other embodiments of the invention are possible. 
For instance, it was mentioned that the present invention can be used in environments 
other than the specific embodiment of health care discussed above. In such other 
environments, the service plan can be viewed as the care plan discussed above, the 
25 customer can be viewed as the patient discussed above and the specific service provider 
user can be viewed as the user or clinician discussed above. The specific types of 
structured sentences, particularly structured sentences for services and related workflows, 



both in terms of metadata and instantiated data, will exist and be unique for that type of 
service provider's business, but will nonetheless be correlated in the same manner as 
described above. Therefore, the scope of the invention should be determined, not by 
examples given, but by the appended claims and their legal equivalents. 
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What is claimed is: 

1 . A method for automatically generating a service plan and associated workflow for 
a customer using a computer based network comprising the steps of: 

creating a plurality of structured sentences for each of a plurality of identified 
customer needs in an electronic storage area, said plurality of structured sentences 
including structured sentences for services, each structured sentence for service 
identifying a needed service corresponding to one of the identified customer needs; and 

creating an electronic workflow capable of assisting completion of each needed 
service. 

2. A method according to claim 1 wherein said step of creating an electronic 
workflow creates a workflow process instance for each needed service, such that there 
exists a workflow process instance associated with each structured sentence for service. 

3 . A method according to claim 2 wherein said plurality of structured sentences have 
a subject and a plurality of attributes contained therein. 

4. A method according to claim 3 wherein certain of the attributes associated with 
the structured sentences for services contain a selected attribute value chosen from among 
a group of possible attribute values. 

5. A method according to claim 4 wherein certain ones of said workflow process 

instances have at least one decision step, task firing condition or routing rules that creates 
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5 a plurality of possible sequences of tasks that are invoked as part of the execution of said 
workflow process instances. 



6. A method according to claim 5 further including the step of modifying at least one 
of the structured sentence attributes, which modification also causes a change to the 

1 0 sequence of tasks invoked within at least one of the workflow process instances. 

7. A method according to claim 5 wherein selecting a different one of the possible 
attributes from among the group of possible attributes will result in the selection of a 
different one of the plurality of possible routes with respect to an associated decision 

1 5 step, task firing condition or routing rule. 

8. A method according to claim 3 further including the step of electronically 
inputting answers to questions, and wherein the electronically input answers to questions 
also causes a change to the sequence of tasks invoked within at least one of the workflow 

20 process instances. 

9. A method according to claim 8 wherein the step of electronically 
inputting answers to questions is performed by the customer. 

25 10. A method according to claim 9 wherein the step of electronically inputting 

answers includes the steps of the customer remotely answering questions and transmitting 
the questions for inputting via the Internet. 

36 



5 



11. A method according to claim 3 wherein certain ones of said workflow process 
instances have at least one decision step, task firing condition or routing rule that creates 
a plurality of possible routes contained therein, and further including the step of creating 
or modifying at least one of the workflow relevant data items, which modification also 

10 causes a change to the sequence of tasks invoked within at least one of the workflow 
process instances. 

12. A method according to claim 2 wherein certain ones of said plurality of workflow 
process instances have workflow relevant data contained therein. 

15 

13. A method according to claim 12 further including the step of electronically 
inputting answers to questions, and wherein the electronically input answers to questions 
are used to create or modify workflow relevant data for certain ones of the workflow 
process instances. 

20 

14. A method according to claim 5 wherein the step of executing a workflow process 
instance further includes the step of performing a query that creates or modifies workflow 
relevant data using query metadata that maps the response options in a question or 
structured sentence data item to the response options in at least one other question or 

25 structured sentence data item, thereby creating a single data value used in a decision step, 
task firing condition or routing rule as part of the execution of said workflow process 
instance . 



1 5. A method according to claim 1, wherein the plan is a care plan, the customer is a 
patient, and the plurality of identified customer needs are health related problems to be 
addressed as part of the patient's care. 

16. A method according to claim 1 5, wherein the step of creating a plurality of 
structured sentences is created by an interdisciplinary team of clinicians. 

17. A method according to claim 1 wherein the step of creating the electronic 
workflow includes creating an alert that will signify that an action needs to be taken. 

18. A method according to claim 1 further including the steps of automatically 
generating a translation of the service plan and transmitting the translation of the service 
plan to the customer. 

19. A method according to claim 1 8 further including the step of revising the 
automatically generated translation prior to the step of transmitting. 

20. A method according to claim 1 8 wherein the step of transmitting transmits the 
translation to a remote computer associated with the customer. 
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5 21 . A method according to claim 1 further including the step of creating other 

structured sentences, said other structured sentences including structured sentences for a 
goal, a fact, a protocol, and a finding. 

22. A method according to claim 1 further including the step of initiating the 
10 workflow. 

23. A method according to claim 22 further including updating the service plan as 
workflow progresses. 

15 24. A method according to claim 23 wherein updates are provided to a user of the 
care plan in one form and updates are provided to the customer in another form. 

25. A method according to claim 24 wherein the one form is directed to a clinician 
and the other form is directed to a nonmedical person. 

20 

26. A method of automatically updating a predetermined plurality of existing service 
plans corresponding to a respective plurality of customers, each of said service plans 
including a plurality of structured sentences for each of a plurality of identified customer 
needs stored in an electronic storage area, said plurality of structured sentences including 

25 structured sentences for services, each structured sentence for service identifying a 
needed service corresponding to one of the identified customer needs and an electronic 
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5 work flow capable of assisting completion of each needed service, the method 
comprising the steps of: 

generating a report based upon data contained within each of the predetermined 
plurality of existing service plans or from data obtained from performing workflow 
associated with each of the predetermined plurality of existing service plans; 
10 selecting a plurality of customers in need of one or more services 

adding new structured sentences that are common to the predetermined plurality 
of existing care plans for the selected plurality of customers; and 

adding workflow instances corresponding to the new structured sentences; and 

causing initiation of the revised workflow instances for each revised service plan. 

15 

27. A method according to claim 26 wherein said plurality of structured sentences 
have a subject and a plurality of attributes contained therein and wherein the step of 
adding new structured sentences includes the step of determining certain of said plurality 
of attributes for said new structured sentences based upon a characteristic that is common 

20 to each of said respective plurality of customers. 

28. A method according to claim 26 wherein said plurality of structured sentences 
have a subject and a plurality of attributes contained therein and wherein the step of 
adding new structured sentences includes the step of individually determining other ones 

25 of said plurality of attributes for said new structured sentences based upon another 
characteristic that is not common for each of said respective plurality of customers. 
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5 29. A method according to claim 26 wherein the step of adding new structured 

sentences further includes the step of modifying certain existing structured sentences that 
are common to the predetermined plurality of existing service plans based upon the data; 
and wherein 

the step of adding workflow instances includes the step of revising workflow 
10 instances associated with the modified certain existing structured sentences. 

30. A method for creating a service plan and associated workflow for a customer 
using a computer based network comprising the steps of: 
providing electronically: 
15 a plurality of structured sentence data items for each of a plurality 

of possible customer needs in an electronic storage area, said plurality of 
structured sentence data items including structured sentence data items for 
services, each structured sentence data item for service identifying a 
needed service corresponding to one of the possible customer needs; 
20 an electronic work flow capable of assisting completion of each 

needed service; and 

at least first and second templates, each of said at least first and 
second templates comprising a different set of certain ones of said 
plurality of structured sentence data items that each relate to different 
25 possible customer needs; 

selecting at least a first template that relates to an identified customer need; and 
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5 selecting those structured sentence data items within the first template that relate 

to the specific need of a particular customer, the step of selecting those structured 
sentence data items also causing the selection of workflow instances capable of assisting 
completion of each needed service. 

10 3 L A method according to claim 30 wherein said plurality of structured sentence data 
items have a subject and a plurality of attributes contained therein and wherein the step of 
selecting those structured sentence data items includes the step of determining the values 
for a plurality of said attributes for corresponding structured sentences in a service plan 
for a customer. 

15 

32. A method according to claim 31 wherein the attribute values for certain ones of 
said plurality of attributes is selectable from a collection mutually exclusive choices. 

33. A method according to claim 3 1 wherein the attribute for certain ones of said 
20 plurality of attributes is a date. 

34. A method according to claim 3 1 wherein the attribute for certain ones of said 
plurality of attributes is a dosage. 

25 35. A method according to claim 30, wherein the service plan is a care plan, the 
customer is a patient, the plurality of possible customer needs are health related 
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5 problems, and the identified customer needs are those health related problems of the 
customer. 



36. A method according to claim 30 further including the step of initiating the 
workflow, the step of initiating the workflow being caused by a user verifying the 

10 accuracy of the service plan. 

37. A method according to claim 30 wherein during the step of providing a plurality 
of structured sentence data items is accomplished by a generic metadata supplier that 
transmits the data to a service provider user, and the service provider user performs the 

1 5 steps of selecting. 

38. A method according to claim 37 further including the step of the service provider 
adding structured sentences to the service plan. 

20 39. A method according to claim 37 further including the step of the service provider 
modifying certain ones of the selected structured sentences from the service plan. 

40. A method of automatically generating the data needed to inform the process of 

updating structured sentence data items and associated workflow process specifications 

25 that are usable for the creation and execution of a service plan, said plurality of structured 

sentence data items including structured sentence data items for services, each structured 

sentence data items for service identifying a needed service corresponding to identified 
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5 customer needs, said associated workflow process specification capable of assisting 

completion of each needed service and including alerts that occur to signify that an action 
needs to be taken, the method comprising the steps of: 

obtaining dismissed alerts associated with existing service plans that include 
correspondence of certain ones of said structured sentences, said dismissed alerts being 
10 designated as one of an appropriate alert and an inappropriate alert; 
grouping related inappropriate alerts; and 

determining a revised workflow and revised structured sentences based 
upon the grouping of inappropriate alerts. 

4L An apparatus for automatically generating a service plan and associated workflow 
for a customer comprising: 

means for creating in an electronic storage area a plurality of structured sentences 
for each of a plurality of identified customer needs for particular customers, said plurality 
of structured sentences including structured sentences for services, each structured 
sentence for service identifying a needed service corresponding to one of the identified 
customer needs; and 

means for creating an electronic workflow capable of assisting completion of each 
needed service. 
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42. An apparatus according to claim 41 wherein said means for creating an electronic 
workflow creates a workflow process instance for each needed service, such that there 
exists a workflow process instance associated with each structured sentence for service. 

43. An apparatus according to claim 42 wherein said plurality of structured sentences 
have a subject and a plurality of attributes contained therein. 

44. An apparatus according to claim 43 wherein certain of the attributes associated 
with the structured sentences for services contain a selected attribute value chosen from 
among a group of possible attribute values. 

45. An apparatus according to claim 44 wherein certain ones of said workflow 
process instances have at least one decision step, task firing condition or routing rule that 
create a plurality of possible sequences of tasks that are invoked as part of the execution 
of said workflow process instances. 

46. An apparatus according to claim 45 further including means for modifying at least 
one of the structured sentence attributes, which modification also causes a change to the 
sequence of tasks invoked within at least one of the workflow process instances. 

47. An apparatus according to claim 45 wherein selecting a different one of the 

possible attributes from among the group of possible attributes will result in the selection 
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5 of a different one of the plurality of possible routes with respect to an associated decision 
step, task firing condition or routing rule. 

48. An apparatus according to claim 43 further including means for electronically 
inputting answers to questions, and wherein the electronically input answers to questions 

10 also causes a change to the sequence of tasks invoked within at least one of the workflow 
process instances. 

49. An apparatus according to claim 48 wherein the means for electronically 
inputting answers to questions is operated by the customer. 

50. An apparatus according to claim 49 wherein the means for electronically inputting 
answers includes means for the customer to remotely answer questions and means for 
transmitting the questions for inputting via the Internet. 

20 51. An apparatus according to claim 43 wherein certain ones of said workflow 

process instances have at least one decision step, task firing condition or routing rule that 
creates a plurality of possible routes contained therein, and further including the step of 
creating or modifying at least one of the workflow relevant data items, which 
modification also causes a change to the sequence of tasks invoked within at least one of 

25 the workflow process instances. 
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52. An apparatus according to claim 42 wherein certain ones of said plurality of 
workflow process instances have workflow relevant data contained therein. 

53. An apparatus according to claim 52 further including means for electronically 
inputting answers to questions, and wherein the electronically input answers to questions 
are used to create or modify workflow relevant data for certain ones of the workflow 
process instances. 

54. An apparatus according to claim 45 wherein the means for executing a workflow 
process instance further includes means for performing a query that creates or modifies 
workflow relevant data using query metadata that maps the response options in a question 
or structured sentence data item to the response options in at least one other question or 
structured sentence data item, thereby creating a single data value used in a decision step, 
task firing condition or routing rule as part of the execution of said workflow process 
instance . 

55. An apparatus according to claim 41 , wherein the plan is a care plan, the customer 
is a patient, and the plurality of identified customer needs are health related problems to 
be addressed as part of the patient's care. 

56. An apparatus according to claim 55, wherein the means for creating a plurality of 
structured sentences is created by an interdisciplinary team of clinicians. 
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5 57. An apparatus according to claim 41 wherein the means for creating the electronic 
workflow includes means for creating an alert that will signify that an action needs to be 
taken. 

58. An apparatus according to claim 41 further including means for automatically 
10 generating a translation of the service plan and means for transmitting the translation of 

the service plan to the customer. 

59. An apparatus according to claim 58 further including means for revising the 
automatically generated translation. 

15 

60. An apparatus according to claim 58 wherein the means for transmitting transmits 
the translation to a remote computer associated with the customer. 

61. An apparatus according to claim 4 1 further including means for creating other 
20 structured sentences, said other structured sentences including structured sentences for a 

goal, a fact, a protocol, and a finding. 

62. An apparatus according to claim 41 further including means for initiating the 
workflow. 

25 

63. An apparatus according to claim 62 further including means for updating the 
service plan as workflow progresses. 
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64. A method according to claim 63 wherein updates are provided to a user of the 
care plan in one form and updates are provided to the customer in another form. 

65. An apparatus according to claim 64 wherein the one form is directed to a clinician 
and the other form is directed to a nonmedical person. 
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Abstract 

A method and system for managing customer service processes for individual 
customers and populations of customers. In a specific embodiment within the health care 
field, a clinician creates or updates a draft care plan for a patient using generic or locally- 
adapted template metadata and tailors the draft care plan to the particular patient. The 
draft care plan includes a list of specific services (health care interventions) to be 
provided to the patient. The draft care plan can be routed to members of an inter- 
disciplinary team for input. Once finalized, workflow processes are instantiated for each 
intervention on the care plan. An itinerary is created for any required patient encounters, 
optimized using an algorithm that considers pre-existing process instances. A workflow 
automation server manages the execution of each workflow process instance, invoking 
resources according to workflow process specification metadata and workflow task type 
metadata. Care plans and encounter itineraries are automatically translated to a patient- 
understandable form and made available to patients online and via printed copy. Clinical 
practice and outcomes data are analyzed to identify opportunities for improvement of the 
metadata. The method and system also allows for the selection of a population of 
patients, the analysis of population data to identify opportunities for interventions 
(needed services), and the initiation of population interventions through batch updates to 
individual care plans. 
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